Can one of the admins verify this patch?

The change will end up deferring to this method in EmbeddedPomParser.java (https://github.com/kiegroup/kie-soup/blob/main/kie-soup-maven-utils/kie-soup-maven-integration/src/main/java/org/appformer/maven/integration/embedder/EmbeddedPomParser.java#L41) and at this location the MavenProject::getDependencies method (https://github.com/apache/maven/blob/maven-3.3.9/maven-core/src/main/java/org/apache/maven/project/MavenProject.java#L281). This core maven code correctly removes the conflicts from the dependencies.

Hi @Hillrunner2008
This code is really used in a broad number of situations (including editors in business central). In this case we need to resolve transitive dependencies as well.
I did left a comment in the jira of this issue.
I think that computing the effective pom is the way to go (also fixes another situatioin regarding offline stuff)
https://issues.redhat.com/browse/JBPM-9829

Please check it and let me know your thoughts . The change is already in 7.59 snapshot.

Hi @Hillrunner2008
This code is really used in a broad number of situations (including editors in business central). In this case we need to resolve transitive dependencies as well.
I did left a comment in the jira of this issue.
I think that computing the effective pom is the way to go (also fixes another situatioin regarding offline stuff)
https://issues.redhat.com/browse/JBPM-9829

Please check it and let me know your thoughts . The change is already in 7.59 snapshot.

The change I made does not remove transitive dependencies, so I'm a little unclear on what you mean. The change only resolves conflicts in the dependency graph. There is no "effective pom" calculation that should ever include conflicts. Maybe I'm missing some context, but in what possible way would having the unresolved graph be useful in one of these many locations you are concerned about impacting? The business central editor and all other relevant code would I believe want to resolve classpath correctly. I think the original author of the code had the intention you are describing (i.e. include transitive dependencies), but they didn't completely think through the implications for a simple traversal and aggregation without conflict resolution.

ok to test

jenkins do fdb

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication

jenkins do fdb

Hi @mareknovotny, @mbiarnes, @elguardian, and @bacciotti,
I submitted this PR a few years ago. At the time, I had personal knowledge of how the bug in question was negatively impacting two different customers. As I explained at the time, it was the effort to prepackage kjar dependencies in an immutable image that led to the discovery of the difference between maven's dependency resolution and the projects internal utility. The side effect of the issue was failed kjar deployments in the immutable containers even when they had the proper dependencies prepackaged.

I definitely never cared for the runtime resolution of classpath from maven repos (instead of binaries like traditional fat jar or war/WEB-INF/lib), but if the use of this utility is going to continue to exist in any supported version of a downstream project I'd imagine merging this PR still would still be beneficial.

I believe I've made the case for this as strongly as I can. However, if there's no movement on this PR the next time I check, I'll plan to close it out as its clearly losing relevance.